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METHODS AND APPARATUS FOR PROVIDING SECURE TWO-PARTY PUBLIC 

KEY CRYPTOSYSTEM 

Field of the Invention 

The present invention relates to cryptography and, more particularly, to techniques for 
5 providing a secure two-party public key cryptosystem implementing Cramer-Shoup based 
decryption. 

Background of the Invention 

A two-party Cramer-Shoup cryptosystem would fall into the general category of threshold 

10 cryptography. There have been previous proposals for threshold cryptosystems secure against 
adaptive chosen ciphertext attack. 

For example, in V. Shoup et al, "Securing Threshold Cryptosystems Against Chosen 
Ciphertext Attack," EUROCRYPT '98, pp. 1 - 1 6, 1 998; R. Canetti et al., "An Efficient Threshold 
Public Key Cryptosystem Secure Against Adaptive Chosen Ciphertext Attack, " EUROCRYPT 

15 '99 (LNCS 1592), pp. 90-106, 1999; M. Abe, "Robust Distributed Multiplication without 
Interaction," CRYPTO '99 (LNCS 1666), pp. 130-147, 1999; S. Jareckietal, "Adaptively Secure 
Threshold Cryptography: Introducing Concurrency, Removing Erasures," EUROCRYPT 2000 
(LNCS 1807), pp. 221-242, 2000; and P. Fouque et al., "Threshold Cryptosystems Secure 
Against Chosen-Ciphertext Attack," ASIACRYPT '01 (LNCS 2248), pp. 351-368, 2001, the 

20 disclosures of which are incorporated by reference herein, cryptosystems are disclosed wherein 
it is assumed that an adversary corrupts / out of n decryption servers. 

Both the V. Shoup et al. proposal and the P. Fouque et al. proposal may be used in the 
two-party case {t = 1, n = 2) if one is only concerned with security and not robustness, but they 
also both use the non-standard assumption that hashes are modeled as random oracles. The 

25 random oracle assumption is discussed in M. Bellare et al., "Random Oracles are Practical: A 
Paradigm for Designing Efficient Protocols," 1 st ACM Conference on Computer and 
Communications Security, pp. 62-73, November 1 993; and O. Goldreich et al., "Random Oracle 
Methodology, Revisited," 30 th ACM Symposium on Theory of Computing, pp. 209-218, 1998, 
the disclosures of which are incorporated by reference herein. 
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Certain of the above-mentioned proposals are based on the Cramer-Shoup cryptosystem. 
R. Canetti et al. assumes that there are users that wish to have messages decrypted; and that 
servers of the cryptosystem do not communicate with each other, but only with the users. R. 
Canetti et al. shows a secure system for n > 2t, a secure and robust system for n > t 2 , and a secure 
5 and robust system for n>2t if the users are given extra per-ciphertext robustness information. 
In M. Abe, the servers are allowed to communicate with each other, and the disclosed techniques 
present secure and robust systems for n > 2t. However, none of these proposals apply to the 
scenario where t = 1 and n = 2. In fact, it is often the case that threshold cryptosystems 
(assuming a strict minority of corrupted players) are developed before the corresponding two- 
1 0 party cryptosystems. 

In summary, previous proposals on threshold cryptosystems secure against adaptive 
chosen ciphertext attack require: (1) the random oracle assumption and are thus not proven 
secure in a standard model; or (2) a strict majority of uncorrupted decryption servers. 

Thus, there exists a need for techniques which overcome the drawbacks associated with 
1 5 the proposals described above and which thereby provide more efficient protocols for performing 
two-party Cramer-Shoup based decryption. 

Summary of the Invention 

The present invention provides a provably secure protocol for a two-party Cramer-Shoup 
cryptosystem. More specifically, techniques are provided for an efficient and provably secure 
20 protocol by which two parties, each holding a share of a Cramer-Shoup private key, can jointly 
decrypt a ciphertext, but such that neither party can decrypt a ciphertext alone. 

For example, in one aspect of the invention, a technique for use in a device associated 
with a first party for decrypting a ciphertext, according to a Cramer-Shoup based encryption 
scheme, comprises the following steps/operations. First, the ciphertext is obtained in the first 
25 party device. Then, the first party device generates a plaintext corresponding to the ciphertext 
based on assistance from a device associated with a second parity, the plaintext representing a 
result of the decryption according to the Cramer-Shoup based encryption scheme. 

The generating step/operation may further comprise an exchange of information between 
the first party device and the second party device whereby at least a portion of the information 
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is encrypted using an encryption technique such that one party encrypts information using its own 
public key and another party can not read the information but can use the information to perform 
an operation. 

The generating step/operation may further comprise an exchange of information between 
5 the first party device and the second party device whereby at least a portion of the information 
is encrypted using an encryption technique having a homomorphic property. 

Further, the first party device and the second party device may additively share 
components of a private key. 

The generating step/operation may further comprise: generating a share of a random 
10 secret; generating information representing encryptions of a form of the random secret, a share 
of a private key, and the ciphertext; transmitting at least the encrypted information to the second 
party device; and computing the plaintext based at least on the share of the random secret, the 
share of the private key, the ciphertext, and the data received from the second party device. 

The generating step/operation may further comprise generation and exchange of proofs 
15 between the first party device and the second party device that serve to verify operations 
performed by each party. The proofs may be consistency proofs based on three-move S- 
protocols. 

Accordingly, in an illustrative embodiment, the secure protocol may use homomorphic 
encryptions of partial Cramer-Shoup decryption subcomputations, and three-move ^-protocols 
20 for proving consistency. 

These and other objects, features and advantages of the present invention will become 
apparent from the following detailed description of illustrative embodiments thereof, which is 
to be read in connection with the accompanying drawings. 

Brief Description of the Drawings 

25 FIG. 1 is a flow diagram illustrating a two-party Cramer-Shoup based decryption protocol 

in accordance with an embodiment of the present invention; and 

FIG. 2 is a block diagram illustrating a generalized hardware architecture of a data 
network and computer systems suitable for implementing one or more of the methodologies 
according to the present invention. 
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Detailed Description of Preferred Embodiments 

The following description will illustrate the invention in the context of an illustrative 
distributed environment implementing Cramer-Shoup based decryption. However, it should be 
understood that the invention is not limited to such an environment. Rather, the invention is 
5 instead more generally applicable to any environment where it is desirable to provide a 
cryptosystem wherein two parties can efficiently perform secure Cramer-Shoup based 
decryption. By way of example and without limitation, it is to be understood that a 

"device," as used herein, may include any type of computing system, e.g., a personal computer 
(including desktops and laptops), a personal digital assistant (PDA), a smartcard, a cellular 

10 phone, a server, a hardware token, a software program, etc. However, it is to be understood that 
the protocols of the invention may be implemented between any two parties or entities using one 
or more of such devices. 

As will be illustratively explained in detail below, the present invention provides an 
efficient and provably secure protocol by which two parties, respectively designated herein as 

1 5 "alice" (or a first party) and "bob" (or a second party), each holding a share of a Cramer-Shoup 
private key, can jointly decrypt a ciphertext, but such that neither alice nor bob can decrypt a 
ciphertext alone. It is to be appreciated that the general concepts and definitions associated with 
Cramer-Shoup encryption/decryption operations are well known in the field of cryptography. 
By way of example, R. Cramer et al., "A Practical Public-key Cryptosystem Provably Secure 

20 Against Adaptive Chosen Ciphertext Attack," CRYPTO '98 (LNCS 1462), pp. 13-25, 1998;and 
R. Cramer et al., "Universal Hash Proofs and a Paradigm for Adaptive Chosen Ciphertext Secure 
Public-key Encryption," EUROCRYPT 2002 (LNCS 2332), pp. 45-64, 2002, the disclosures of 
which are incorporated by reference herein, describe details on Cramer-Shoup 
encryption/decryption operations. 

25 Advantageously, the present invention provides a provably secure protocol for a two-party 

Cramer-Shoup cryptosystem. The invention may be used in accordance with a variety of 
applications. 

By way of one example, the invention can be used for a secure distributed third-party 
decryption service, which requires the joint agreement by two parties to decrypt a ciphertext. For 
30 example, this may be used to provide added security to: (1) a key recovery system by law 
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enforcement, e.g., S. Micali, "Fair Public-key Cryptosystems," CRYPTO '92 (LNCS 740), pp. 
113-138, 1992, the disclosure of which is incorporated by reference herein; or (2) an "offline 
trusted third party" system in a fair exchange protocol, e.g., N. Asdkan et al., "Optimistic 
Protocols for Fair Exchange," 3 rd ACM Conference on Computer and Communications Security, 
5 pp. 6-17, 1996, the disclosure of which is incorporated by reference herein. 

Another application involves techniques by which a device that performs private key 
operations (signatures or decryptions) in networked applications, and whose local private key is 
activated with a password or PIN (personal identification number), can be immunized against 
offline dictionary attacks in case the device is captured, e.g., P. MacKenzie et al., "Networked 

10 Cryptographic Devices Resilient to Capture," DIMACS Technical Report 2001-19, May 2001, 
extended abstract in 2001 IEEE Symposium on Security and Privacy, May 2001; and the U.S. 
patent application identified as Serial No. 10/072,33 1 , filed on February 7, 2002 in the name of 
P. MacKenzie et al., and entitled "Methods and Apparatus for Providing Networked 
Cryptographic Devices Resilient to Capture," the disclosures of which are incorporated by 

1 5 reference herein. 

Briefly, the goal of immunization against offline attack may be achieved by involving a 
remote server in the device's private key computations, essentially sharing the cryptographic 
computation between the device and the server. The above work by P. MacKenzie et al. shows 
how to accomplish this for the case of RSA (Ri vest- Shamir- Adleman) functions and certain 

20 discrete-log-based functions. 

The work in P. MacKenzie et al., "Two-party Generation of DSA Signatures," CRYPTO 
2001 (LNCS 2139), pp. 137-154, 2001; and the U.S. patent application identified as Serial No. 
10/183,900, filed on June 26, 2002 in the name of P. MacKenzie et al., and entitled "Methods 
and Apparatus for Two-Party Generation of DSA Signatures," the disclosures of which are 

25 incorporated by reference herein, provides techniques for immunization against offline attack in 
accordance with two-party DSA signatures. 

The present invention may be implemented so as to provide techniques for immunization 
against offline attack in accordance with two-party Cramer-Shoup encryption/decryption 
operations. Moreover, the inventive cryptosystem makes no extra assumptions beyond those 

30 made in the original Cramer-Shoup cryptosystem (disclosed in the above-referenced work by 
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R. Cramer et al.), and the inventive cryptosystem is proven secure in the standard model (without 
random oracles). 

To achieve the above and other features and advantages, the invention introduces novel 
techniques including the use of homomorphic encryptions of partial Cramer-Shoup decryption 
5 subcomputations, and special three-move ^-protocols for proving consistency. These ^-protocols 
are especially noteworthy in that: (1) they are not required to be (fully) zero-knowledge, and are 
used as proofs of consistency rather than proofs of knowledge, and thus they can be used in a 
concurrent setting (since neither simulation of pro vers nor extraction of witnesses is needed); and 
(2) their secure use relies in a fundamental way on the hardness of DDH (Decision Diffie- 
10 Hellman), though their soundness and (honest- verifier) zero-knowledge properties do not. 

Before explaining an illustrative protocol of the invention, we first introduce some 
definitions and notations which will be used in accordance with the explanation. 

Security parameter. Let k be the cryptographic security parameter used for, e.g., hash 
functions and discrete log group orders. Exemplary values may be k = 160 or k = 256. 
1 5 Notation and definitions. We use (a, b) x (c, d) to mean element- wise multiplication, i.e., 

(ac, bd). We use {a, b) r to mean element- wise exponentiation, i.e., (a \ b"). For a tuple V 9 the 
notation V\j] means the f h element of V. 

Let G q denote a finite (cyclic) group of prime order q, where \q\ = k. Let g be a generator 
of G q , and assume it is included in the description of G q . Note that in the following definitions 
20 and descriptions, we will relax notation slightly and let G q denote its own description. For 
instance, when we say the input to a function is G q , we mean that the input is the description of 
the group G q . 

R 

Let " z <— S" denote the assignment to z of an element of S selected uniformly at random. 

Let s denote equivalence modulo q. 
25 Encryption schemes. An encryption scheme eis a triple (G £ , E, D) of algorithms, the first 

two being probabilistic polynomial-time, and the last being deterministic polynomial time. G c 
takes as input G q and outputs a public key pair (pk, sk), i.e., (p/r, sk) <— G e (G q ). Note that, for 
convenience, instead of using input 1*, we will simply use a fixed group G q with \q\ = k and 
define encryption schemes over this group. E takes a public key pk and a message m as input and 
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outputs an encryption c for m; we denote this c <— E pk (m). D takes a ciphertext c and a secret key 
sk as input and returns either a message m such that c is a valid encryption of m under the 
corresponding public key, if such an m exists, and otherwise returns an arbitrary value. 

Now we define the Cramer-Shoup encryption scheme using a fixed universal one-way 
5 hash function H and over a fixed group G q , in which solving DDH is difficult. Note that one 
possible group G q may be found by generating a large prime p such that q divides p - 1, and 

letting G q be the subgroup of order q in % 

G cs (G q ): Let g be the generator of G q (implicitly included in the description of G q ). 

R R abed 

Generate g 2 <— G q , and a, 6, c, tf, e <^Z q , and set U<- g (g 2 ) , v g (g 2 ) > and 

10 W <r- g , Let <g, g 2 , £/, V 9 W> be the public key and <a, 6, c, d, e> be the secret key. 



E <g>g ,U,V,tV>( m ^ : Generate r<-Z and compute x i-g" ,y <-(g 2 ) r ,w ^ W r m, 



<j <-H(x, y, w), and v ^— U r V m . Return <x, y, w, v> as the ciphertext. 

D <Q b c d e> ( < x >y> w > v > ) : Generate <r<-H(?c 9 y, w). If v * x?*™ }^ d \ return _l, else 
return w/x e . 

1 5 The above-referenced work of R. Canetti et al. gives a variation of this protocol in which 

R 

D <a b c d e > ( <x > w > v> ) generates a as above, but then generates s <r- Z and returns 

» ■ ' 9 q 

w/(x e (v/vy\ where V = x a+c<r y ,+rf<T . One can see that for invalid encryptions (those in which the 
original D function returns _l) the new decryption function will return a completely random value, 
and for all other encryptions, the new decryption function returns the same value as the original. 
20 The two-party protocol of the invention is able to perform the R. Canetti et al. variation of the 
decryption procedure. 
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System model. The inventive system includes two parties, alice and bob, who obtain 
public and secret data through a trusted initialization procedure. Here we will simply assume 
alice and bob receive all their public and secret data from a trusted party. After initialization, 
communication between alice and bob occurs in sessions (or decryption protocol runs), one per 
5 ciphertext that they decrypt together. Alice plays the role of session initiator in the decryption 
protocol. That is, alice receives requests to decrypt ciphertexts, and communicates with bob to 
decrypt these ciphertexts. We presume that each message between alice and bob is implicitly 
labeled with an identifier for the session to which it belongs. Multiple decryption sessions may 
be executed concurrently. 

1 0 " There is a network that alice and bob use to communicate with each other in the inventive 

protocol. For purposes of the proof of security, we may assume an adversary controls the 
network, inserting and manipulating communication as it chooses. In addition, the adversary 
takes one of two forms: an alice-compromising adversary that has perpetual read access to the 
private storage and computation of alice, and a bob-compromising adversary that has perpetual 

15 read access to the private storage and computation of bob. 

We note that a proof of security in this two-party system extends to a proof of security 
in an n-party system in a natural way, assuming the adversary decides which parties to 
compromise before any session begins. The basic idea is to guess for which pair of parties the 
adversary decrypts a ciphertext without the assistance of the non-corrupted party, and focus the 

20 simulation proof on those two parties, running all other parties as in the real protocol. The only 
consequence is a factor of roughly n 2 lost in the reduction argument from the security of the 
encryption scheme. 

Labeled ciphertexts. Note that in this illustrative scenario, alice decides on which 
ciphertexts to decrypt. This removes the need to include in the illustrative model separate users 
25 that communicate with alice and bob to obtain decryptions, and allows us not to have to change 
the encryption scheme to use explicit labels. Of course, the Cramer-Shoup encryption scheme 
does allow an easy way to introduce labels, and this could also be done in the inventive protocol. 
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1. Definition and Basic Theory of L-protocoIs 

The illustrative two-party decryption system of the invention, to be described in detail 
below, may use special types of D-protocols to deal with malicious adversaries. Thus, here we 
overview the basic definitions and properties of E-protocols. ^-protocols are generally described 
5 ,in R. Cramer et al., "Proofs of Partial Knowledge and Simplified Design of Witness Hiding 
Protocols," CRYPTO '94 (LNCS 839), pp. 174-187, 1994; andR. Cramer, "Modular Design 
of Secure Yet Practical Cryptographic Protocols, Ph.D. Thesis, CWI and University of 
Amsterdam, 1997, the disclosures of which are incorporated by reference herein. 

First, we start with definitions and notation. Let R = {(x, w)}be a binary relation and 

10 assume that for some given polynomial /?(•) it holds that |w| < p(\x\) for all (x, w) 6 R. 
Furthermore, let R be testable in polynomial time. Let L R = {x : 3w, (jc, w) e R} be the language 
defined by the relation, and for all x e L R , let W R (x) = {w : (x, w) e R} be the witness set for x. 
For any NP language L, note that there is a natural witness relation R containing pairs (jc, w) 
where w is the witness for the membership of x in Z,, and that L R = L. 

15 Now we define a E-protocol (A, B) to be a three-move interactive protocol between a 

probabilistic polynomial-time proverb and a probabilistic polynomial-time verifier B, where the 
prover acts first. The verifier is only required to send random bits as a challenge to the prover. 
For some (x 9 w) e R, the common input to both players is x while w is private input to the prover. 
For such given x, let (a, c, z) denote the conversation between the prover and the verifier. To 

20 compute the first and final messages, the prover invokes efficient algorithms <z(0 and z(-), 
respectively, using (x,w) and random bits as input. Using an efficient predicate (p (•), the verifier 

decides whether the conversation is accepting with respect to x. The relation R, the algorithms 
a(*X z(-) and cp (•) are public. The length of the challenges is denoted t B , and we assume that t B 

only depends on the length of the common string x. In the following, we will always use 
25 challenges randomly drawn from Z q . 

This definition is slightly broadened to deal with cheating provers. We will define L R 
to be the input language, with the properties that L R cz L R s anc j that membership in L R ma y 
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be tested in polynomial time. We implicitly assume B only executes the protocol if the common 

input x € L R m 

All S-protocols presented here will satisfy the following security properties: 

1. weak special soundness: Let (a, c, z) and (a, c\ z') be two conversations, that are 
5 accepting for some given x. If c * c\ then x e L R . Often these protocols are assumed to satisfy 

special soundness: On input x and those two conversations, a witness w such that (x, w) e R can 
be computed efficiently. We do not need special soundness for the illustrative results. The pair 
of accepting conversations (a, c, z) and (a, c\ z f ) with c * d is called a collision. 

2. special honest verifier zero knowledge (special HVZK): There is a (probabilistic 
10 polynomial time) simulator M that on input x e L R generates accepting conversations with the 

exact same distribution as when A and B execute the protocol on common input x (and^4 is given 
a witness w for x), and B indeed honestly chooses its challenges uniformly at random. The 
simulator is special in the sense that it can additionally take a random string c as input, and output 
an accepting conversation for x where c is the challenge. In fact, the simulator will have this 

15 special property for not only x e L R , but also any x e L R m 

A simple but important fact is that if a S-protocol is HVZK, the protocol is perfectly 
witness indistinguishable (WI), e.g., U. Feige et al., "Witness Indistinguishable and Witness 
Hiding Protocols," 22 nd ACM Symposium on Theory of Computing, pp. 416-426, 1990, the 
disclosure of which is incorporated by reference herein. Although HVZK by itself is defined 
20 with respect to a very much restricted verifier, i.e., an honest one, this means that if for a given 
instance x there are at least two witnesses w, then even an arbitrarily powerful and malicious 
verifier cannot distinguish which witness the prover uses. 

As an example, we give a S-protocol (A DH , B DH ) for R DH , the Diffie-Hellman relation over 

G Q , i.e., R DH = {(g\ h, h\ w)} where h =g w and K = (gT, and L D = ( G / . Given public 

k dh q 

25 input (g\ h, h 1 ), say A DH knows w such that ((g\ h, A'), w) e R DH . For its first message, A DH 
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chooses r - Z q9 computes y - g and/ «- (g') r , and outputs (y,/). On challenge c, A DH computes 
s - wc + r and outputs 5. B DH verifies g = h c y and (g') s = - 

In the illustrative results to follow, we use a generalization of a corollary in R. Cramer 
et al. ("Proofs of Partial Knowledge and Simplified Design of Witness Hiding Protocols," 
5 CRYPTO '94(LNCS839),pp. 174-187, 1994) which enables a pro ver, given two relations (R l9 

R 2 ) 9 values (x x ,x 2 ) e L x L , and corresponding 3-move E-protocols ((A X9 B x ) 9 (A 29 B 2 )) 9 

to present a 3-move S-protocol {A or9 B or ) for proving the existence of a w such that either (*„ w) 
e R l or (x 2 , w) e R 2 . We call this the "OR" protocol for ((A u 5,), (A 29 B 2 )). 

We will describe the protocol assuming the challenges from (A u B x ) and (A 2 , B 2 ) are of 

1 0 the same length. This can easily be generalized, as long as the challenge length in the combined 
protocol is at least as long as the challenges from either protocol. The protocol comprises (A u 
B } ) and (A 2 , B 2 ) running in parallel, but with the verifier's challenge c split into c = Cje c 2 , with 
c x as the challenge for (A u B x ), and c 2 as the challenge for (A 2 , B 2 ). 

The protocol for A or is as follows: Without loss of generality, say A or knows w such that 

15 (jc„ w) e R x . Let M 2 be the simulator for S 2 . Then A or runs M 2 (x 2 ) to generate (m, e, z). The 
protocol sends the first message of (A l9 B x ) 9 along with m as the first message of (A 29 B 2 ). On 
challenge c 9 the protocol chooses c 2 = e 9 and c x =c® c 2 . The protocol is able to provide the final 
response in (A X9 B x ) because it knows w 9 and the final response in (A 29 B 2 ) is simply z. The final 
message of A or includes c x along with the final responses for (A X9 B x ) and A l9 B 2 ). 

20 For a relation R 9 let E[7?] denote a S-protocol over R. For a predicate P 9 let S[P] denote 

J][R] for the relation R defined by P 9 with public values defined by P. Furthermore, let L p = L R 

and L = L , for the relations defined by P. Let S[JT, y] denote the "OR" protocol for (S[X|, 



2M). 
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2. S-CS System 

In this section, an illustrative system, called S-CS (for "Secure Cramer-Shoup"), is 
described by which alice and bob can jointly decrypt Cramer-Shoup ciphertexts, according to an 
embodiment of the present invention. 

The S-CS system will be illustratively described in accordance with the above-mentioned 
immunization against offline attack application. Such application naturally admits a trusted party 
for initializing the system. Alternatively, in accordance with the present invention, one could 
build a distributed initialization protocol involving only alice and bob, and no trusted center. To 
achieve provable security, this initialization could be executed in a sequential manner prior to 
any decryption sessions, even though the decryption sessions themselves may be executed 
concurrently with respect to each other. 

Specifically, in accordance with the illustrative embodiment, we assume a trusted party 
is given a (public) group G q with generator g and generates a Cramer-Shoup public key along 
with secret values for alice and bob to allow decryption: 



R 



82 <" <V 



R 



a l ,a 2 ,b l .b 2 .c l ,c 2 ,d l ,d 2 ,e l ,e 3 <- Z q , 



<u l ,u 2 > <- <g ax (g 2 ) b \g a2 (g 2 ) b2 >, 
<v v v 2 > <- < g c > (g 2 ) d \g Cl (g 2 ) dl >, 



< w v w 2 > <- <g e ' ,g e2 >, 



R 




P 2 



>, 
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The trusted party gives alice the values <a x , b u c u d u e u fi x >, gives bob the values <a 2> b 2 , c 2 , d 2 , 
e 2 >, and gives both alice and bob the values: 



< g,g 2 ,U l M 2 ,V 2 ,W v W 2 ,h v h 2 ,D l ,D 2 ,L> 3 ,D[,D! 1 ,D^ > 

Letting U ^U X U 2 ,V '<- V x V 2 and W+-W x W 29 the Cramer-Shoup public key is <g,g 2 , 
5 £/, V, W>, Note that this public key is drawn from the same distribution as in the standard 
Cramer-Shoup key generation. Also note that only this public key is necessary for encryption, 
and not the partial public key values £/„ U 29 etc. 

With respect to this initialization, it is easy to see how the standard Cramer-Shoup private 
keys are split between alice and bob, with their associated public values. Next, the h x and h 2 
1 0 values will be used as ElGamal (e.g., T. ElGamal, "A Public Key Cryptosystem and a Signature 
Scheme Based on Discrete Logarithms," IEEE Transactions on Information Theory, 3 1 :469-472, 
1985, the disclosure of which is incorporated by reference herein) public keys for alice and bob, 
respectively. Note that it is not necessary for bob to receive /? 2 , since bob does not need to 
decrypt anything encrypted with h 2 . Encryptions using h 2 will simply be used for consistency 
15 checking, as described below. Finally, the D x , D 2 , D 2 , D[ , D[ , D[ values are used in order to 

make consistency proofs work in the concurrent setting based on DDH. 

2.1 Decryption Protocol 

Referring now to FIG. 1 , a flow diagram illustrates a two-party decryption protocol in 
accordance with an embodiment of the present invention. In particular, FIG. 1 illustratively 

20 depicts a protocol 100 by which alice and bob cooperate to decrypt ciphertexts with respect to 
the public key <g, g 2 , U, V, W>. This is referred to as the S-CS protocol. As input to this 
protocol, alice receives a ciphertext c to be decrypted. Bob receives no input (but receives c = 
<x, y 9 w, v> from alice in the first message). The predicates ¥ , *F f , T, and T' used for 
consistency checking are displayed without their parameters in the figure for readability. We 

25 give their full descriptions below, with parameter names that correspond to the parameters in the 
S-CS protocol. 
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The decryption protocol proceeds as follows. Upon receiving c to decrypt, alice first 
generates a share s, of a random secret s as used in the above-described R. Canetti et al. variant 
of Cramer-Shoup decryption. Steps 102 and 104 respectively illustrate generation of hash 
function CJ and generation of s u r l9 r 29 r 3 , r 4 , in accordance with the Cramer-Shoup decryption 

5 described above. Then, alice generates ElGamal encryptions of x Sl ,y Sl ,v s * 9 and 

— ( a x + c x a ) —(b x + d x o ) 

x y (respectively, in steps 106, 108, 110 and 1 12). All of these values, 

except v 5 ' , are needed by bob to be able to perform bob's part of the decryption, but it is 

necessary to include v S} for consistency checking, and more specifically, for the protocol ' s proof 
of security. Alice generates these encryptions under the public key h l9 for which she knows the 

10 secret key. Finally, alice proves that she has generated these encryptions consistently. 

Alice sends bob c and the four encryptions in step 114. Exchange 116 denotes the three- 
round proof that is particular to the S-protocol. The proof is in the form of "commit" (sent from 
alice to bob), "challenge" (sent from bob to alice), and "response" (sent from alice to bob, who 
then verifies the response). 

15 Once bob receives c and the four encryptions from alice and accepts the proof, bob 

generates the hash function and his own share s 2 of s (respectively, in steps 118 and 120). Note 
that this is an intuitive description since s itself is actually determined by s x and s 2 . Next bob uses 
the homomorphic properties of the ElGamal encryption scheme used by alice to compute an 
encryption (still under the public key for which alice knows the secret key) of a partial decryption 

20 of c, using the first, second, and fourth encryptions sent by alice (step 1 24). Then, bob generates 

ElGamal encryptions of x Sl ,y S2 ,v Sl ,and x ~^ (a ^ ClP) y-^^J (respectively, in steps 126, 

128, 130 and 132) under the public key h 2 , for which the secret key is not known to alice. 
Finally, bob proves that he has generated these encryptions consistently. Note that the extra 
encryptions are not necessary for any computations of alice, but are used for consistency 
25 checking, and more specifically, for the protocol's proof of security. 

Bob sends alice the encryptions in step 1 34. Exchange 136 denotes the three-round proof 
that is particular to the S-protocol. Again, the proof is in the form of "commit" (sent from bob 
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to alice), "challenge" (sent from alice to bob), and "response" (sent from bob to alice, who then 
verifies the response). 

When alice receives the encryptions from bob and accepts the proof, alice decrypts the 
encryption containing bob's partial decryption of c, and then finishes the decryption of c using 
5 her local values step 138. In step 140, the result of the two-party Cramer-Shoup decryption is 
output. 

Given g, g 2 , c = <oc,y, w, v>, and o = H(x, y 9 w), the predicates *F , ' , T , and F ' are 
defined as follows: 



V[U X ,V X ,E X ,E 2 ,E 3 ,EJ def 



3r x ,r 2 ,r 3 ,r 4 ,a l ,b 1 ,c x ,d l ,s x : 

V l =g l (g 2 )^ 
E x =(g r \(hJ>x s >) 

E 2 =(g r \(h x r y s >) 

E z = (g\(hJ>v s >) 
a E 4 =(g\(hJ*x- (ai+Cia) y- {bi+dia) ) 



10 



^[U 2i V 2y W 2 E 59 EUE^E^ def 



f 2 =*"'(&)■ 



^2 

W 2 =g" 

A E s ={g\(h x Y' x" (vx Ha 1 * c > a) y- 02 V ) 
x(£,)" (aj+C!<,) xiE^-" 2 *"^ x(E A Y' 

E;=(g\(h 2 ) r 'x s >) 

£ 2 '=(g ; ,(/» 2 ) r; / ! ) 

E;=(g r K(h 2 y>v>) 



E;=(g\(h 2 y x(e;) 



x(E;y 



f> (b 2 +d 2 o) 
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T[D X ,D 2 ,DJ = [3r:D x =g r *D 3 =(D 2 f J 
def 

T'[D[,D[,D[ = [3r:D[=g r *D\, = (D\f ] 

The encryptions of alice are defined to be consistent if holds, but instead of simply 
constructing S[ *¥ ] to prove consistency, alice constructs S[ *F , T ], proving that either *F 
holds, or the triple (D u D 2 , D 3 ) is a Diffie-Hellman triple. Since (£>„ Z) 2 , Z) 3 ) was chosen 
5 randomly in initialization, most likely it will not be a Diffie-Hellman triple, and thus alice will 
essentially be proving that *F holds. The reason for including T is that we will be able to use it 
to simulate the E-protocols for alice, by having our simulator set (D„ D 2 , D 3 ) to be a Diffie- 
Hellman triple in the initialization protocol. By the hardness of DDH, this should not noticeably 
affect the adversary. Note that this technique works in the case of static adversaries, and in 
1 0 particular, bob-compromising adversaries, since setting (D, , D 2 , D 3 ) to be a Diffie-Hellman triple 
may also allow an adversary to give a valid proof 2 [ *F , T ] without \|/ holding. However, it is 
easy to see (and follows from the proof) that a bob-compromising adversary gains no advantage 
from this. 

The encryptions of bob are defined to be consistent if V F' holds, and the reasoning 
1 5 behind the S[ *F 9 , P] construction is similar to the reasoning behind the S[ *F , T ] construction 
of alice. S[ *F , T ] and S[ 4*' , V ] may be similar to other protocols for proving relations 
among discrete logs, e.g., J. Camenisch et al., "Proof Systems for General Statements about 
Discrete Logarithms," Technical Report TR 260, Department of Computer Science, ETH Zurich, 
March 1 997, the disclosure of which is incorporated by reference herein, and are given below. 
20 At this point, we have stated that E 3 and E\ for 1 <> i <, 4, as well as the two S- 

protocols, are used for consistency checking, and thus one might believe that they could all be 
removed from the protocol if one were only to consider security against "honest-but-curious" 
adversaries. However, this does not seem to be true. The S-protocols and could in fact be 
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removed, but the other values serve another purpose in our security proofs, namely, to allow a 
simulator for one of the parties to obtain the results of partial decryption computations from the 
other party. Thus, if one were to consider the "simplified" protocol for honest-but-curious 
adversaries, only E' A and the S-protocols would be removed, leaving alice and bob to send values 

5 to each other that are never actually used. 

It is also to be noted that our simulator does not require knowledge of the other party's 
share of the decryption randomizer s, but only the results of partial decryption computations. 
These can be encrypted and checked for consistency easily, using techniques that rely solely on 
the hardness of DDH. This is one of the important advantages of the invention, since having the 

10 simulator obtain s itself, although not difficult to achieve in threshold Cramer-Shoup protocols 
assuming an honest majority, seems to require a much more complicated two-party protocol, and 
in fact may not admit a protocol whose security relies solely on the hardness of DDH. 

As shown in FIG. 1, the illustrative protocol 100 may employ six messages (assuming 
message 1 14 and the first message from alice to bob of exchange 116 are combined into one 

1 5 message; and assuming message 1 34 and the first message from bob to alice of exchange 1 36 are 
combined into one message). This could be improved to four messages by using the "committed 
proof technique of S. Jarecki et al. "Adaptively Secure Threshold Cryptography: Introducing 
Concurrency, Removing Erasures," EUROCRYPT 2000 (LNCS 1807), pp. 221-242, 2000; or 
I. Damgard, "Efficient Concurrent Zero-knowledge in the Auxiliary String Model," 

20 EUROCRYPT 2000 (LNCS 1 807), pp. 41 8-430, 2000, the disclosures of which are incorporated 
by reference herein. In particular, one could replace bob's proof S[ ¥ ' , T ' ] by a committed 
proof of Sf^F' ,T' ], where, in particular,^ is kept secret until the third message of the 

committed proof. This would allow the proofs by alice and bob to be interleaved, since E 5 

would not be revealed until after bob verifies that holds. This would be a novel application 
25 of the committed proof technique, i.e., it would be used not for the purpose of obtaining security 
against adaptive adversaries, but for improving efficiency. 

It should also be noted that the inventive protocol could be reduced to two messages using 
the standard Fiat-Shamir technique, e.g., A. Fiat et al., "How to Prove Yourself: Practical 
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Solutions to Identification and Signature Problems," CRYPTO ' 86 (LNCS 263), pp. 186-194, 
1987, th disclosure of which is incorporated by reference herein, for making proofs non- 
interactive using a hash function to calculate a challenge, but then a proof of security would 
require the random oracle assumption. 

Turning to computational complexity, one can see that each party must perform roughly 
90 exponentiations. Although this number is somewhat high, most of the exponentiations are 
performed over one of a small number of bases, and thus preprocessing can be used to greatly 
reduce the computation time. Also, assuming that the group is of size q where \q\ = 160, the 
exponents are reasonably small (roughly 160 bits each). 

3. Protocols S[ ¥ ] and 2[ 4" ] 

In this section, we present protocols for S[ *F ] and 2[ *F' ]. These protocols may be 
proven secure. Protocols 2[ *F , T ] and S[ *F' , r '] can be constructed using the techniques 
described in section 1 above. 

15 3.1 E[ *P ] 

5 

Consider the predicate *F = *¥ [U u V l9 E u E 2 , E 3 ] with input language L y = ( G q ) . 
We assume g 9 g 29 h u xj,ve G q and aeZ q are fixed. We assume the prover knows a l9 b u c„ d l9 

r l> r 2> ^3? S \ ^ Z q . 

The first prover message of S[ *F ] is: 
20 < U X ,V X ,E X ,E 2 ,E 3 >, 

R 

where ? x , r 2 , ? 3 , a, , £ x , c, , d x , S x <r- z q and 



5 



10 
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v x <- g Sl (g 2 /' i 2 «- r/ 2 . (\ f 2 /' ; & <- r / 4 . r*. ; ' 4 /' + * CT /' + A CT 



Given a challenge/?, the second prover message for E[i|/] is <z l5 z 2 , z 3 , z 4 , z 5 , z 6 , z 7 , z 8 , z 9 >, 

where: 



Zj <- r jP + z 4 <- r 4 p + P 4 z 7 <~ c x p + Cj 

Z 2 *~ r 2 P + *2 Z 5 *~ a \ P +a \ Z 8 *~ ^1 P + *1 

Z 3 <~ r 3 P + ^3 Z 6 *~ *1 P + *1 Z 9 5 1 P + *1 

The verifier then verifies that: 



r ^ / * e x = r^^ 1 . / l * Z9 ; / o l = / 6 

(E 2 / x E 2 = (g* 2 , (h x / 2 y* 9 ) (V x / V x = g 1 (g 2 / 8 

(E 3 f x E 3 = (g Z3 , (h x / 3 v Z9 ) 

f£: 4 ; *E 4 = (g ,(h x ) x y ) 



3.2 2[*F'] 

Consider the predicate *F' = [C/ 2 , F 2 , JT 2 , £ 5 , £y , £ 3 \ E\ \ with input 
language Z^, ~(G q ) . We assume g, g 2 , /r„ h 2 , x,y,ve G q and <r e Z q are fixed. We assume 
1 0 the prover knows : 
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a 2 ,b 2 ,c 2 ,d 2 ,r 5 ,r;,r±,r;,r; t s 2 eZ. 



The first prover message of the £[ *F ' ] is: 



<U 2 ,V 2 ,W 2t E 5r E[,E' 2 ,E'„ElE':>, 
where a 2 ,b 2 ,c 2 ,d 2> e 2 ,s 2 ,r{,r 2 \r^,rl > rl',% '<-Z and 



<- r r* 2 ; «/ a <- / 2 / 2 

£ 2 <- r / 2 . r* 2 / 2 / 2 ; v 2 g ^ ( gl / 2 

r" r" £' C' 

E';<r- (g r *,(h 2 f*)x i y° ) 

K - r/ 5 . (h, A ^ v* /'/' ; x r *. ;"^ 2 + ^ K ( e 2 + ( e 3 /■ 



■2 



Given a challenge p, the second prover message for S[ *F ' ] is: 

< Z \> Z 2> Z l> Z A> Z 5> Z 6> Z T Z %> Z 9> Z \Q> Z \\> Z \2> Z n> Z \A >r 



where: 



2 , r ,'P + 
z 2 <r- r 2 'p + r 2 ' 

2 3 «" r 3 P + ^ 

z 5 <- (r 4 » - r« 2 + c 2 a >/ - fZ> 2 + rf 2 a > 2 ';p + r 4 " 
z 7 <-a 2 p +a 2 
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z 9 <-c 2 p + c 2 

z n <^s 2 p+s 2 

2,3 < (a 2 +c 2 a )s 2 p +£' 



The verifier then verifies that: 



r*;/ x^; \(h 2 ) ■* 12 j (u 2 f u 2 = g 1 (g 2 ) 8 

(E' 2 ) P xi' 2 - (g Z2 , (h 2 / 2 /» ) (V 2 / V 2 = ^ 2 /" 

r^/xi;. r/ 4 , r * 2 /« ; * ^; / rz7 + Z9CT ; x r* 2 i (z% + z,0 ° } 



(e>J x£ 4 » = r* ,5 .r* a / 5 x x,3 / M ; 



fz 7 + z 9 a; -fz 8 + z 10 a; 



5 4. Illustrative Architecture 

Referring now to FIG. 2, a block diagram illustrates a generalized hardware architecture 
of a distributed data network and computer systems suitable for implementing a two-party 
Cramer-Shoup decryption protocol (e.g., S-CS) between two parties (e.g., "alice" and "bob") 
according to the present invention. As shown, the first party (alice) employs a computer system 
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202 to participate in the protocol, while the second party (bob) employs a computer system 204 
to participate in the protocol. The two computer systems 202 and 204 are coupled via a data 
network 206. The data network may be any data network across which the two parties desire to 
communicate, e.g., the Internet. However, the invention is not limited to a particular type of 
5 network. 

The computer systems in FIG. 2 represent "devices," as mentioned above. The devices 
may be, for example, personal computers (including desktops and laptops), personal digital 
assistants (PDA), smartcards, cellular phones, servers, hardware tokens, software programs, etc. 
However, the invention is not limited to any particular device. 

10 As is readily apparent to one of ordinary skill in the art, the computer systems of FIG. 2 

may be implemented as programmed computers operating under control of computer program 
code. The computer program code is stored in a computer readable medium (e.g., a memory) and 
the code is executed by a processor of the computer system. Given this disclosure of the 
invention, one skilled in the art can readily produce appropriate computer program code in order 

1 5 to implement the protocols described herein. 

In any case, FIG. 2 generally illustrates an exemplary architecture for each computer 
system communicating over the network. As shown, the first party device comprises I/O devices 
208-A, processor 21 0-A, and memory 2 12- A. The second party device comprises I/O devices 
208-B, processor 21 0-B, and memory 212-B. It should be understood that the term "processor" 

20 as used herein is intended to include one or more processing devices, including a central 
processing unit (CPU) or other processing circuitry. Also, the term "memory" as used herein is 
intended to include memory associated with a processor or CPU, such as RAM, ROM, a fixed 
memory device (e.g., hard drive), or a removable memory device (e.g., diskette or CDROM). 
In addition, the term "I/O devices" as used herein is intended to include one or more input 

25 devices (e.g., keyboard, mouse) for inputting data to the processing unit, as well as one or more 
output devices (e.g., CRT display) for providing results associated with the processing unit. 

Accordingly, software instructions or code for performing the protocols/methodologies 
of the invention, described herein, may be stored in one or more of the associated memory 
devices, e.g., ROM, fixed or removable memory, and, when ready to be utilized, loaded into 

30 RAM and executed by the CPU. 
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Although illustrative embodiments of the present invention have been described herein 
with reference to the accompanying drawings, it is to be understood that the invention is not 
limited to those precise embodiments, and that various other changes and modifications may be 
made by one skilled in the art without departing from the scope or spirit of the invention. 



